AWSチーム社内勉強会「Ansible」レポート

はじめに

こんにちは、虎塚です。

先週金曜日の18:30から1時間、AWSコンサルティング部でAnsibleをテーマに社内勉強会を開催しました。この記事では、会社の活動紹介を兼ねて、勉強会の様子をレポートします。

秋葉原オフィスと札幌オフィスにいた社員、東京や札幌近郊でリモート勤務中の社員10名以上が、Skype接続して実施しました。写真は、秋葉原オフィスの会議室に集まったAWSチームメンバーです。

今回の講師は植木さんでした。植木さん自身も上越からのリモート参加で、Skypeを使って画面共有しながら説明とデモを実施してくれました。上の写真で皆がディスプレイを食い入るように見ているのは、そのためです。

Ansibleの説明

デモンストレーション

• Ansibleをインストールする
  • brew install ansible
• ssh/configを作成する
  • ここで.ssh/configを自動生成するスーパー便利スクリプトが披露されました。（詳細は、【AWS】EC2のインスタンス情報からssh/configを作成するRubyスクリプト ｜ Developers.IOを参照ください）
• Inventoryファイル（hosts）を用意する
  • ホストのグループを定義できる
  • グループを入れ子にできる
  • 対象外のグループやホストを先頭「#」で除外できる
• ansibleコマンドを実行する
  • -sでsudoしてくれる
• ansibleコマンドをまとめるために、playbookを書く
  • 複数のタスクを定義できる（例: Apacheのインストール）
• playbookを実行する
  • ansible-playbook -i hosts playbook.yml

Ansibleを使うために用意する必要があるのは、最低限hostsファイル（Inventory）だけ。

playbookの実行結果として、ok / changed / unreachable / failed といった状態が表示される。たとえば、Apacheをインストールするタスクの場合、同じホストに対して再度実行すると、もうインストールの必要がないため、実行結果には単にokと表示される。「changed」は、タスクを実行する事前事後のサーバの状態を見て判断し、出力される。

タスクを使って、ApacheやMySQLのconfigの値を変更することなどができる。テンプレートとして置き換えることも、今ある値を書き換えることもできる。

参考資料

• Ansible入門 (全15回) - プログラミングならドットインストール
• 入門Ansible [Kindle版]
  • 伊藤直也さんのChef本とおなじくらい分かりやすいとのこと
• Ansibleの公式ドキュメント

その他、Ansibleをすでにバリバリ使っている望月さんが書いたplaybookが社内のリポジトリにごっそりあるので、生きた教材として参考にしよう、という話も出ました。

質疑応答とディスカッション

「Ansibleだとこれはできるの？」「Chefと比べてどうなの？」といったカジュアルな議論ができました。また、今回はあくまでも入門、導入編でしたので、各自がこれからAnsibleを使っていく中で確認しようという事項がいくつか出ました。

Q: もしかしてAnsibleってJenkinsと連携すると便利？

A: シェルスクリプトのラッパーなのでその通り。ここでは宛先ホストすべてにシェルコマンドを流し込むクライアント、くらいの意味で「シェルのラッパ」と書きました。正確な表現でないことをお詫びします。ブックマークコメントにてご指摘いただきました。ありがとうございます。

Q: 今（勉強会）ではローカルマシンの履歴として実行結果を表示しているが、コンソールに出力するようにすれば、Jenkinsに保存できる？

A: Jenkinsのジョブ履歴から実行結果を見られるはず。

Q: Ansibleを使って設定ファイルの書き換えはできる？ Tomcatのポートを8080から80に変更するとか

A: たぶんできる。

Q: 設定ファイルはツールによってフォーマットが異なるよね。どうやって違いを吸収してるの？

A: sedのような単なる文字列置換でがんばっているのでは

Q: 既存のファイルをまるごと差し替えることもできる？

A: できる。便利。詳しいやり方は、ドットインストール参照。

Q: yamlはコメントが書ける？

A: Yes.

Q: 実行ログは1ファイルに出力される？ 複数サーバに実行したら、サーバごとに格納される？

A: デモで見せたログファイルは、ターミナルに出てくる文字をリダイレクトしただけ。ログをファイル出力するオプションがあるかも？

Q: 複数のサーバに対してタスクを実行した場合、詳細ログはどのような形式で出てくる？

A: 混ざらずにホストごとに出力される。実行は並列だけど、結果表示は逐次なのか？ 少なくとも、サーバ単位にログ出力されているように見える

Q: 並列実行ってどうやるの？

A: Ansibleコマンドを -f FORKSオプションを付けて実行する。デフォルトはFORKS=5

Q: Ansibleコマンドでverboseオプション（-vvv）を付けると何が表示される？

A: SSH接続の詳細や、実行結果のJSONが返ってくる

Q: Windowsと連携できる？

A: Windows上でも使えるらしい。chocolateyと連携できるかも

dry runについて

Ansibleコマンドには、checkやdry runの機能もあります。Ansibleのタスクが複数のステップからなる場合、最後の状態が分からないので、dry-runは無理ではないか？という能登さんの問題提起から、そもそもdry-runに何を求めるかという議論になりました。

これについては、実行する前に何が変更されるかを見たい、特に、実行時に消えてしまうリソースや入れ替わるリソースを知りたい、という主張が多かったです。

AWS環境でいうと、CloudFormationなら、スタックがロックされるのが怖いから事前に見たい。Route 53のRoadworkerも同じ思想で、間違えて別のレコードを消すことを避けたいから使う。といった話が出ました。dry-runで変数展開が行われると、実際に適用される設定が分かるので嬉しいですね。

複数台に対して実行する時はdry-runで何が出力されるのか？という疑問が出ましたが、よく分からないので各自やってみようという結論になりました。

Chefとの比較

Ansibleでは、タスクをyamlで定義するしかないため、Chefほどきめ細かいことはできない印象です。

Chefを使うと、Rubyで書けるので究極的には何でもできますが、レシピは混沌とします。何でもかんでもできないほうがよい場合もある、という話になりました。

とはいえ条件分岐は欲しい、という意見も上がりました。これについては、playbookにタスクを書くとき、whenキーワードで記述できます。また、そもそもplaybook内で処理を分岐するよりも、playbookを記述するタイミングで動的に分岐した方がよいのではという意見が出ました。

Q: Chefのrole（サーバ機能によってcookbookを分けたり）やenvironment（キーを分けたり）のようなことはAnsibleでできる？

A: できないのでは。どうでしょう？

AWSとAnsible

AnsibleはChefと同じくらい冪等性を重視するツールなのか？という質問が都元さんから出ました。

AWSの思想には、冪等であることよりもイミュータブルの方がマッチするのではないか。冪等性を捨ててシンプルにいきたいが、Ansibleはそれにマッチするだろうか？という議論が、質問の意図だったようです。リトライすれば全部一緒の状態が作られること（＝冪等性の担保）がやっぱり嬉しい、という意見もありました。

CloudFormer（CloudFormationに熟達した者をこう呼びます）の都元さんは、AnsibleがEC2インスタンスの中で自分自身をセットアップするような用途に使えるかについても気にされていました。こちらは、playbookをどこかから持って来れるならOKのようです。たとえば、playbookをS3に置いておいて、利用時にEC2内部からダウンロードすればよいですね。

AnsibleでInfrastructure as Codeをはじめよう

Ansibleの利用は、Infrastructure as Codeの手始めによいのではないか、という意見が出ました。Ansibleは、要はSSHラッパーです。Chefよりさらにシェルスクリプトを直接実行する形に近く、導入の敷居がとても低いのが特徴です。上記のデモンストレーションも、Inventoryを作るだけで実行されました。

また、管理される側にエージェントが必要ない点も嬉しいですね。Chefでは、クライアントにもエージェントをインストールする必要があります。

Ansibleのように手元のシェルスクリプトをどんどん実行するためのツールとしては、FabricやCapistranoが元々ありました。小さめの案件で、ぱぱっと気軽に構築したい時によさそうです。

Ansibleコマンドで実行可能なシェルスクリプトの種類は、宛先ホストの環境に依存します。Chefなら、環境を調べてyumを使うかaptを使うかを勝手に決め、依存性を見てライブラリを導入してくれます。が、Ansibleはそういうことはしません。

このことからも、AnsibleはChefよりもずっとシンプルな用途に向いているらしいことが分かります。Chefの抽象化層は厚く、たとえばApacheをインストールするだけのレシピで、数多くのプラットフォームに対応した結果、数万行に膨れ上がることもあるそうです。

デモンストレーションで扱ったもの以外のモジュールについては、公式ドキュメントを参照してください。command moduleやec2 moduleなど、いろいろあります。

おわりに

あっという間の1時間でした。講師の植木さん、皆さん、お疲れさまでした＆ありがとうございました！

Ansibleを使ったことがないメンバーの取っ掛かりに、という当初の目標は十分果たされたと思います。勉強会の後、植木さんオススメのドットインストールを見てみました。とても分かりやすくて、導入にはぴったりでした。参加したメンバーの中には、Ansibleをさっそく構築業務で使いはじめた梶さんのような人もいます。

メンバーのいる場所が離れていても、ツールを駆使すれば皆で勉強会に参加できてすばらしいですね。

それでは、また。